Azure API Management Service Policy-based Logging

Unlock comprehensive, policy-based logging for your Azure API Management Service APIs with Nodinite. This guide shows you how to capture every request and response—including payloads and headers—without intrusive code changes or data loss.

✅ Capture full payloads and headers for every API request and response
✅ Eliminate data loss—extract and reindex new fields anytime
✅ Apply granular retention policies by message type
✅ Integrate non-intrusively with your existing solutions
✅ Gain actionable insights and ensure compliance with ease

Info

This guide teaches you how to apply a Nodinite-specific policy to enable logging from the Azure API Management Service platform.

Why Choose Nodinite Logging Over Application Insights and Competing Solutions?

In today’s fast-paced business environments, you need more than just data collection—you need actionable insights and complete context. While tools like Application Insights and other platforms require predefined logic to capture key values, Nodinite Logging removes the guesswork, prevents data loss, and gives you long-term flexibility.

🚀 Nodinite Logging vs. Application Insights & Other Competitors

1. Full Payload Logging—No Predefined Logic Needed

• With Nodinite, you avoid coding up-front logic to extract key values like correlation IDs, order numbers, or transaction details.
• Log all message payloads and context values in full, ensuring you always have complete visibility.
• If you forget to log a value with Application Insights or similar tools, it’s lost forever. With Nodinite, you can extract and index new fields at any time.
• Nodinite imposes no size restriction, unlike many other options.

Key Advantage: You don’t need developers to anticipate every logging requirement—log everything and extract later as needed.

2. Flexible Search & Reindexing—No More Data Loss

• Competing solutions make it too late to add a new search field after logging.
• Nodinite lets you create new search fields and reindex old data anytime, preserving historical context.
• If you extract a field incorrectly, just fix the expression and reindex—no data lost.

Key Advantage: You avoid data loss from changing business needs or mistakes in log field definitions.

3. Non-Intrusive, Policy-Based Logging

• Unlike Application Insights, which requires custom logging code, Nodinite uses a policy-based, non-intrusive approach.
• Log in parallel with your existing monitoring solutions—no application changes required.

Key Advantage: Achieve low performance overhead, no intrusive code changes, and full flexibility to run alongside existing tools and policies.

4. Granular, Message-Type Level Retention

• Competing solutions limit retention by fixed days or quotas, forcing you to choose between losing logs or paying more.
• Nodinite lets you define retention per message type, so you keep high-value transactions longer and purge less important logs earlier.

Key Advantage: Optimize retention based on business value, not arbitrary limits or storage constraints.

🔥 The Bottom Line: Why Nodinite Wins

✅ Log everything—no upfront coding required
✅ Prevent data loss—reindex old data anytime
✅ Log large payloads—no message size limits
✅ Integrate non-intrusively—run alongside existing solutions
✅ Control retention—keep critical logs longer without extra cost

Tip

With Nodinite, you never have to say "I wish we had logged that." Everything is available when you need it.

This guide presents three ways to create and send the Nodinite Log Event.

Diagram: Policy-based logging and event flow for Azure API Management and Nodinite.

When you activate the policy (Blob Storage Policy or Event Hub Policy), the code running in Azure API Management creates a Nodinite-specific JSON Log Event and sends it to intermediate storage.

The Nodinite Pickup Log Events Service Logging Agent collects the Nodinite Log Events from the intermediate store (Event Hub or Blob Storage Container). This pattern is Asynchronous.

Tip

Use the Nodinite Non-Events Monitoring Agent to get alerts if you have too many or too few events within a period.

Body

Log the full payload. If you use the Blob Storage Policy, message size does not matter. If it is <200KB, use the Event Hub Policy. Storing the payload in Nodinite lets you use Search Fields in Log Views to create a rich, on-demand user experience for your business.

Important

When you log the payload, provide a name for the Message Type.

You can change the body display using Stylesheets. This lets you hide content as needed. Use Role-based security to control who can access and view content.

Context

A Nodinite Log Event supports a Context—a collection of key-value pairs. Along with HTTP Headers, you can add properties in the Logging policy. Later, use these to create Search Fields for self-service Log Views.

Request Headers	Response Headers

Screenshots: Example of request and response headers captured by Nodinite logging.

Tip

You can add to your policy exactly which properties to include in the Logging.

If you log too much, adjust the following System Parameter:

• ContextPropertiesFilters

Since you control Logging in the Policy, you determine what to include up front.

Troubleshooting

Contact our Support if you need help implementing Logging.

Logging Options

The diagram below shows the different options for logging from Azure to Nodinite.

Diagram: Logging options from Azure to Nodinite, including API Management, Functions, and Logic Apps.

If you log from the API policy to an Event Hub entity, you can reuse the Event Hub entity if the content is a Nodinite JSON Log Event.

Important

EH1, EH2, and EH3 must each have their own syncpoint (bookmark)—one blob storage container for each event hub entity and client.

• Use the Blob Storage Policy if possible for less administration and large message support.
• Logging from Azure functions can share the same Event Hub as APIM if the Log Event is a Nodinite JSON Log Event.
• Logging from Azure Logic Apps requires other event hubs as targets since the content is in a different format.

Using a shared Event Hub for a Nodinite JSON Log Event reduces administration (configure the Nodinite Pickup Log Events Service Logging Agent to fetch these events).
The disadvantage can be performance-related, or you may need to consider pricing, scalability, retention, and number of partitions.

Tip

Use separate event hub entities for different purposes and needs—multiple Logic App Logging, multiple API Management Services, multiple APIs, multiple Azure functions, all according to your architecture.

Important

Do not use the same Event Hub Entity for Logic Apps Logging as for Serilog and Policy-based solutions. Diagnostics from Logic Apps are from Microsoft, while the others create a Nodinite JSON Log Event. These cannot appear on the same Event Hub Entity.

Next Step

Pickup Log Events Service Logging Agent
Azure Application Access

Related Topics

JSON Log Event
Managing
Monitoring
Non Events Agent
Stylesheets

Interested in logging from other Azure Related Services?

• Logging from Azure Logic Apps
• Logging from Azure functions